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Abstract 

The WWW is a popular multimedia browsing system on the Intern^ today. Not only static information, many 
people want dynamic and real-time information from WWW servers. The relalional databases, which used as a 
compon^t of information systems, are suitable for source of such a dynamic information. We tried to browse 
information on a relational database from WWW clients, and found thai some of the complicated database access 
applications needs a concept of session", although the current WWW mechanisDo. doesn't have one. We propose a 
simple session management mechanism on WWW systems for such applications. 
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Abstract: 

The WWW is a popular multimedia browsing system on the Internet today. 
Not only static information, many people want dynamic and real-time information from 
WWW services. The relational databases, which used as a component of information 
systems, are suitable for source of such a dynamic information. We tried to browse 
information on a relational database from WWW clients, and found that some of the 
complicated database access applications needs a concept of "session", although the 
current WWW mechanism doesn't have one. We propose a simple session 
management mechanism on WWW systems for such applications. 
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2. Elemental Technology 
2.1 WWW 

The structure of the WWW and its connectivity are shown in Fig. 2.1. The 
WWW is made up of clients and servers both connected through the Internet and 
functions basically as follows. 

When a user manipulates a client, the user have to specify a particular name, 
which is given uniquely to the Internet resource and which is called URL (Uniform 
Resource Locator) for required information. The URL is broadly classified into three 
units: (1) Protocol Locator, (2) Server Locator, and (3) Server Resource Locator. The 
client makes use of the Domain Name Service mechanism to acquire the IP address of 
the server from the server's denomination (domain name). 

If the protocol locator is http:, the client makes a direct connection with the 
server according to the TCP/IP and provides the server with the URL of the desired 
information and information on the data format acceptable to the client. The server 
then interprets the incoming URL and then send the most relevant information to the 
client in form of the MIME messages, followed by disconnection. This protocol 
(HTTP) has the following features. 



Publicly open standard, the specification of which has been published. 



Connection and disconnection according to the TCP/IP is carried out each time 
a request is made. 

A variety of information including texts, images and voices can be acquired 
monogenically. 

A certain connectionless protocol can be included having been capsulated. 

Also, since the URL has a letter string to express a particular protocol, any 
arbitrary protocol can be expressed in terms of combination. This allows the URL to 
be expanded in the future to cope with the protocol used the WWW. 

2.2 VGUIDE 

The VGUIDE (Visual and General User Interface for Database Environment) 
was chosen as a database function for connection with the WWW. This VGUIDE was 
developed by NTT and is a middleware for the development of database-oriented 
custom application programs and systems based thereon. It provides the client-server 
type database access functionalities under the multi-vender environment and a 
development platform for the custom application utilizing these functionalities. The 
structure of this VGUIDE is schematically shown in Fig. 2.2. The client and the server 
can accommodate the database and the custom application, respectively and it makes 
possible to develop a database access system in an open manner from a side tool for 
individual businesses to a nationwide system. 

3. Coordination System 

Where reference is made from the WWW client to the data stored in the 
database (DB), since the both are a client-server type, the following coordination of the 
combinations can be contemplated in view of the respective structures of the DB and 
WWW systems. 

System 1: The DB server concurrently serves as the WWW server. 

The DB server is added with a mechanism for interpreting the HTTP to enable 
it to function as a WWW server. 

As compared with any other systems, overhead hierarchies are so small that a 
high performance can be obtained. 

However, since the information model differs between the WWW and the DB 
server, not only is it necessary for the flow of information between those systems to be 
properly switched, but also the DB server must be remodeled and, thus, more work is 
required than to newly construct the WWW server. 

System 2: Installation of the Gateway Server 



The gateway server for converting the protocol between the WWW client and 
the DB server is installed. The gateway server is used to stand ready for the WWW 
server, receive a request from the WWW client, make access to the DB server as a DB 
client based on the request and return the access result back to the WWW client. 

When the external script activated interface CGI (Common Gateway Interface) 
possessed by the WWW and the custom application (AP) of the VGUIDE are utilized, 
the WWW server, WWW client and DB server can be realized with no need to be 
remodeled. 

However, since the overhead resulting from the relay is unavoidable, problems 
on the performance appear to arise. 

System 3: To Allocate the Function of the DB Client to the WWW client 

This is reverse to the System 1 and the dedicated WWW client to which the DB 
client functionality to the WWW client is connected direct with the DB server. 

This is featured by an addition to the protocol description of the URL without 
the existing DB server being modified. 

However, it is often that the protocol generally employed in the DB client is 
special and not open to the public. In the case of this system, modification is 
necessary to the WWW client and, considering the necessity of making access from the 
public, it is extremely difficult to circulate the modified WWW client. If the WWW 
comes to have a function of freely incorporating the processing portion of the protocol 
externally into a module, it can be contemplated that it be so incorporated into a module 
so that only the protocol processing portion can be circulated, but it is impossible at this 
time. 

In this experiments, the system 2 (Installation of the Gateway Server) was 
employed because since it can readily be realized, the purpose of the experiments is to 
verify the possibility of coordination and no evaluation is needed with respect to the 
performance. 

In view of the availability, the CERN httpd was employed in the WWW server 
on the gateway server. 

4. Experiments: 

The details of the experiments conducted to make access from the WWW client 
to the DB will be described. 

4.1 Experiment 1 and Experiment 2 

Verification was made of the basic access to the database through the WWW 



and results of search in the text format. 

In this Experiment 1, the script and the VGUIDE custom application (AP) were 
started up in response to a request from the WWW client and a fixed pattern 
incorporated in the VGUIDE custom AP was searched. Through the custom AP, the 
search result was delivered to the script, and the search result in the script was converted 
into the HTML language, which was in turn transmitted to the WWW client with the 
search result displayed. 

In the Experiment 2, search conditions in the SQL language were inputted in 
response to the form input of the WWW client and were then delivered to the custom AP, 
followed by the search made in a manner similar to that in the Experiment 1 to display 
the search conditions under a specific condition. 

4.2 Experiment 3 

The experiment was conducted to display the DB search results, based on 
grouped and integrated assignment, in the text and the circle graph. 

For manipulation, three stages were taken; (1) selection of the table, (2) 
selection of the column and (3) database search. 

The table selection is to select one of the tables in the database, that is used for 
the search and is accomplished by outputting the look-up table from the VGUIDE 
custom AP so that the form input of the WWW client can select the requisite table. 

The column selection is to causing the different VGUIDE custom AP to output 
all of the columns in the table selected in the manner discussed above, so that the form 
input of the WWW client can select one of the columns. 

During the database search, the SQL is generated using the selected table and 
the selected column and the VGUIDE custom AP makes access to the database. The 
search result outputted by the custom AP is not only converted into the HTML in a 
manner similar to that in the Experiment 1, but delivered to the graph generating 
program utilizing the ghostscript to generate a graphic image, which is in turn 
embedded in the search result in the previously converted HTML format and then 
forwarded to the WWW client to provide a display combining the both. 

However, embedment of the image in the HTML is accomplished by, while the 
image itself exist in a different site, only URL of such image is embedded in the HTML 
itself so that the WWW client can combine the both. While in the static embedment no 
problem occurs since the fixed URL is embedded, no fixed URL can be used where 
different images are generated from the search data. 

In view of this, a unique string of numbers is generated using, and stored as a 
temporary file name, the time of execution of the search and the process ID of the 
executed script and the image file and the URL are generated under such file name and 



are then embedded in the HTML. 

4.3 Experiment 4 

An attempt is made to achieve a display mider two kinds of views in different 
formats for displaying the details of the individual data and in a look-up format for 
displaying the single DB search result in its entirety. 

For the search, the fixed pattern was employed. An object to be searched was 
an employee information table and the entire search was specified.. 

When the search is specified from the WWW client, the VGIDE custom AP 
was started to conduct the search. The search result was delivered onto the script and, 
out from the search results, the look-up HTML was generated using the "name of the 
employee" information and, at the same time, the URL for the individual display was 
added to each item of the look-up display. Also, from the search results, the HTML for 
the individual display was generated using all data of the search results. 

The HTML for the individual display was generated by generating a temporary 
file name from the time -process ID -record number in a manner similar to that in the 
Experiment 3 and was stored therein. 

4.4 Experiment 5 

Verification was conducted to ascertain the operation to deliver the DB search 
results to the other application through the WWW client. 

The HTTP contains information concerning the contents in a header of the 
telegraphic message to be returned to the WWW client. With the CGI script, the 
"Content-Type" indicative of the "type of information" is controllable and this was 
utilized. In the first place, search conditions were specified from the WWW client to 
assign the search. The search was carried out by the VGUIDE custom AP and, after 
the header descriptive of the designated output type has been outputted, the search 
results are outputted in that type. For example, in the case of the data, in which a tab is 
used to separate the columns, the header is "Content-Type: text/tab-separated-values". 

On the other hand, in the WWW client, an external application is specified 
depending on the type of information. In this way, mere assignment of the search is 
effective to deliver the DB search results onto the external application. 

5. Problems 

With respect to the problems which occur when the WWW is utilized for 
publication and collection of the various information on the industry and also for pay 
services and acceptance of an order, we will describes what has been clarified through 
those experiments. 



5.1 Session 

The legitimate problem associated with realization of the interface with the 
database lies in a so-called "connectionless", in which HTTP connection and 
disconnection are repeatedly made during the access. In the ordinary database, DBMS 
(database management system) retains various conditions such as transaction state, set 
of search results and locked state while performing the process. In the case of the 
database being handled, it is necessary to make an access while the server and the client 
recognize those conditions. 

When access is indirectly made from WWW to the database, the database is not 
handled directly and, accordingly, it appears that all of those conditions need not be 
retained, but some kind of session function or another appears to be necessary as the 
individual search results or the like are necessary for each individual user. 

5.2 Development Environment 

The experiments we had now conducted were on a small scale and, therefore, 
all were individually prepared with shell scripts and C-pro grams. However, where in 
practice pages are to be generated, which accommodate the services, it appears some 
development assistances are required. 

5.3 Others 

The following enumerates some problems which appear to arise when the 
services on a commercial scale are carried out. 

Problem on cache of the WWW client 

The WWW client is provided with a cache for locally storing data once 
accessed. However, no warrant is available that the caching function is necessarily 
mounted and no cache size is specified. For this reason, if something is generated on 
the assumption that the cache is employed, there is a high possibility that an unexpected 
operation may occur such as display of data ambiguous with the previous search result 
when the search is again conducted at an unexpected timing. 

To alleviate this problem, it appears that some countermeasures such as 
utilization of the session function are required even when the search is conducted. 

Security 

With the HTTP 1.0, the data are transmitted without being encrypted. 
Although this is not problematic so far as the information is published to the unspecified 
public in general, unauthorized utilization of the unencrypted data such as tapping by 
the third party will occur particularly where supply of services and information to 
specific persons utilizing any identifier such as, for example, the membership services 
and the ordering of goods are concerned. 



However, this problem appears to be partly remedies and the public key 
encryption system is currently considered. In the future, it appears that a secure 
WWW server-client communication will takes place using the encryption system. 

Performance 

Where the server is operated as a commercial server, it is suspected that the 
case with the existing servers suggests a substantial amount of accesses will take place. 
The current implement requires a substantial amount of overheads since the script 
start-up and the process start-up and connection are repeated for each time. Any 
framework appears to be necessary so that a substantial amount of processing can be 
handled where it is provided for the commercial server. 

6. Session 

As the foregoing problems indicate, the HTTP has no concept of "session". 
During this experiment, portion of countermeasures with respect to this problem has 
been carried out, which will now be discussed, 

6.1 Simple Session System 

When Experiments 3 and 4 are conducted, it is necessary to display the same 
search results after they have been converted in format between different connections. 
For this reason, the unique number must be generated based on the search time and the 
process ID of the search script as discussed previously, and is then used as a so-called 
session identifier to identify the different connections for access to the same search 
results. This system is herein referred to as the "Simple Session System". 

6.2 Problems in Simple Session System 

In the simple session system discussed above, the session can be realized on an 
experiment level, but the following problems will be highlighted where the simple 
session system is employed on practical services. 

" Appropriation by the Third Party 

In the case where something regular such as time and process ID is used for the 
session identifier, there is the risk that it may be inferred by the third party. In other 
words, the third party may appropriate the particular session. 

To alleviate this problem, it may be suspected to use the hard-to-identify 
session identifier comprised of random numbers. However, although the probability 
may be low, there remains a problem associated with the appropriation caused by the 
chance attack. Accordingly, for practical countermeasures against the appropriation, it 
may be suspected that the appropriation of the session by the third party may be 
achieved by the utilization of the security functions, which would be sophisticated in the 
future as discussed previously and, at the same time, by retaining a set of the "user 



identifier" for limited users and the conventional "session identifier" as a "internal 
session identifier" of the server. 

Determination of Session Terminating Timing 

In this system, the session identifier is generated by the WWW server and the 
WWW client retains it as link information so that when the WWW client user utilize it, 
reference can be made to different data in the same session. However, since the HTTP 
is used as a transmission protocol, no information is available how the session identifier 
once deacquired is retained in the WWW client or how the session identifier is disposed 
of. For this reason, the period during which the information associated with the 
session on the part of the server is retained, that is, the point of termination of the 
session is not clear. 

At present, since no effective countermeasure is available, in this experiment 
the session information on the part of the server is discarded after a predetermined 
length of time. In other words, the session is extinguished after a predetermined length 
of time subsequent to the start of the session. 

7 Conclusion 

It has been confirmed that coordination between the WWW and the database 
makes it possible for the WWW client to make access to the database server due to the 
installation of the gateway server. It appears that a variety of information can be 
provided for as information is provided according to those new systems. 

The experiment conducted is associated with the WWW and access can be 
made easily from the outside. We wish that in the future, public experiments on the 
system experimented can be made to verify coordination between the WWW and the 
database access, including verification of the practical applicability and those updated. 
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